home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Magnum One
/
Magnum One (Mid-American Digital) (Disc Manufacturing).iso
/
d21
/
qemmnote.arc
/
OPTIMIZE.TEC
< prev
next >
Wrap
Text File
|
1991-06-26
|
19KB
|
402 lines
ID:OP Quarterdeck's OPTIMIZE Program
Quarterdeck Technical Bulletin #191
by Russell Bell
The purpose of this document is to give a brief statement of what the
OPTIMIZE program does and explain in detail how to handle common problems
that can occur when it is run.
1) What is OPTIMIZE?
OPTIMIZE.COM is a program Quarterdeck supplies with its
memory managers (QEMM-386 and QEMM-50/60) and its memory
enhancer, QRAM. The same program is used on all three products.
In this bulletin references to QEMM-386 should be construed
to apply to all three products. The technote is not directly
related to the functioning of DESQview but DESQview may have more
memory available for its windows if the system has been
OPTIMIZEd.
2) What does OPTIMIZE do?
The purpose of the OPTIMIZE program is to configure the
CONFIG.SYS and AUTOEXEC.BAT to leave the computer with the most
conventional memory (the memory below 640 kilobytes) possible and
the largest possible remaining areas of High RAM. OPTIMIZE does
nothing permanent to the computer other than edit the CONFIG.SYS
and AUTOEXEC.BAT. All the work that OPTIMIZE does can be done by
the user by hand or reversed by hand in whole or in part. The
OPTIMIZE program does it more quickly and almost always better.
3) How does OPTIMIZE work?
The first step of OPTIMIZE copies the CONFIG.SYS to
CONFIG.QDK and the AUTOEXEC.BAT to AUTOEXEC.QDK so that, if
OPTIMIZE fails for some reason, or if the user wishes to return
to the configuration before OPTIMIZation, the original system
files are available.
The second step of OPTIMIZE puts the "RAM" parameter on the
QEMM-386 command line and runs "LOADHI/GS" on all the device
drivers in the CONFIG.SYS and all the TSRs in the AUTOEXEC.BAT
and then reboots the computer. For QRAM users the RAM parameter
is redundant: QRAM creates high RAM automatically. On systems
with DOS versions 2.x and 3.x all the buffers (except one) will
be moved from the CONFIG.SYS to the AUTOEXEC.BAT to load them
high. On systems with DOS version 4 it is a more efficient use
of memory to load the buffers into expanded memory using the DOS
feature, the "/x" parameter. Quarterdeck's BUFFERS.COM cannot be
used with DOS 4. See below for a further discussion of this
issue. OPTIMIZE uses the "/GS" parameter to determine how much
memory a driver or TSR requires to be loaded into memory.
If the AUTOEXEC.BAT ends with a program that remains in
control of the computer (such as a menu program) rather than
exiting to DOS then you must exit that program to continue
OPTIMIZation.
The third step of OPTIMIZE actually loads the device drivers
and TSRs high. If it fails, the old CONFIG.SYS and
AUTOEXEC.BAT are restored.
If all the device drivers and TSRs can be loaded high then
OPTIMIZE will load them all high and leave a new CONFIG.SYS and
AUTOEXEC.BAT on the system. If they cannot all be loaded high,
OPTIMIZE runs through all possible configurations and chooses the
ones that leave the most conventional memory available. If the
OPTIMIZE process has completed then the screen will read:
The OPTIMIZE process is complete.
If it does not then something has gone wrong.
THE LOADHI UTILITIES
1) What does LOADHI do?
LOADHI.COM loads resident programs (TSRs) into the high RAM
created by QEMM-386 (or QEMM-50/60 or QRAM). LOADHI.SYS performs
the same function for device drivers.
2) What can LOADHI not do?
LOADHI.SYS cannot load high any program or driver that loads
more than two programs or drivers in turn. LOADHI.COM cannot
load the programs in a batch file high. If you are calling a
batch file from the AUTOEXEC.BAT then you must put its contents
explicitly in the AUTOEXEC.BAT in order for OPTIMIZE to load them
high. Alternatively you may load them high by editing the batch
file yourself as described in the LOADHI chapter of the manual.
3) How much memory is needed to load a program high?
LOADHI must have enough memory available to load a program.
A program may use more memory to load than to remain resident.
LOADHI/GS reports both the amount of memory needed to load and
the amount needed to stay resident. The amount of memory needed
to load, not just the amount needed to stay resident, must be
available in one contiguous block for a program to be loaded
high. OPTIMIZE creates a file named "LOADHI.OPT" in the QEMM (or
QRAM) directory that contains two numbers for each TSR or device
driver: the memory size needed to load the TSR (or device driver)
and the memory size needed for it to stay resident.
4) Why does my program not load high?
Some programs refuse to be loaded high. They may be
unwilling to be loaded above conventional memory or they may
refuse to be crammed into the region in which OPTIMIZE puts them
or they may have some other complaint. These programs are rare,
but there is no fix for their objection.
If a program (or device driver) does not remain resident
there is no point in loading it high. This can be discovered by
looking at the second number LOADHI/GS reports (or the second
number in LOADHI.OPT): if this number is 0 then the program does
not stay in memory and does not need to be loaded high.
5) How can I tell what is being loaded high?
Running "LOADHI" with no parameters or programs to load will
give a status report indicating what the high RAM regions are,
what is loaded into them, and what areas are available. The
First Meg/Programs page of Manifest also shows what programs are
loaded high as well as those loaded low.
TROUBLESHOOTING
1) What should I do if OPTIMIZE fails?
If OPTIMIZE does not end by reporting "The OPTIMIZE process
is complete," you should look at your CONFIG.SYS and AUTOEXEC.BAT
to see if they are unchanged. If they are as they were in the
beginning then OPTIMIZE has not completed. If the CONFIG.SYS
contains "DEVICE=C:\QEMM\RSTRCFG.SYS **** OPTIMIZE S%tep 2 [or 3]
****" and the AUTOEXEC.BAT is "@OPT2" or "@OPT3" then OPTIMIZE
has failed and you should restore CONFIG.QDK to CONFIG.SYS and
AUTOEXEC.QDK to AUTOEXEC.BAT. If the CONFIG.SYS and AUTOEXEC.BAT
do not have these lines in them, and they are not as they were
before running OPTIMIZE, and LOADHI reports that there are
programs loaded high, then OPTIMIZE was successful and you just
missed the message "The OPTIMIZE process is complete".
2) What can go wrong?
A) In general:
If you have a third-party disk partitioner then drives other
than C: sometimes do not exist until it is loaded. In these cases
if you put QEMM-386 on any drive other than the C: drive, the disk
partitioner must be loaded first.
OPTIMIZE cannot OPTIMIZE a CONFIG.SYS or AUTOEXEC.BAT longer
than 512 lines.
DOS does not allow lines longer than 128 characters in the
AUTOEXEC.BAT.
During the OPTIMIZE process lines are temporarily lengthened. If
you have a very long line, OPTIMIZE may increase it to more than 128
characters long. Shorten such a line if possible. If this is not
possible then using the "/PATH" switch on OPTIMIZE may help. See the
section on "switches" below. OPTIMIZE may also fail in certain rare
circumstances if QEMM-386 is the first line in the CONFIG.SYS. Try
putting something harmless that does not get loaded high in the
CONFIG.SYS before the QEMM-386 line, such as the "FILES=??" command
(where "??" is the amount of FILES you want to load in the
CONFIG.SYS).
Some error messages may be reported during the optimization
process that can be ignored, since OPTIMIZE proceeds normally
after reporting the error. For example:
--OPTIMIZE reports an error when it finds a batch file being
loaded in the AUTOEXEC.BAT, reporting that batch files cannot be
loaded high.
--If you are using a command processor other than Microsoft's
COMMAND.COM (such as 4DOS) that has internal commands that Microsoft's
DOS does not have, LOADHI will not recognize them. LOADHI will treat
such a command as an external command, reporting a "file not found"
error when it is encountered.
B) In the first step:
All that happens in the first step of OPTIMIZE is that
backup copies of the CONFIG.SYS and AUTOEXEC.BAT are made to
CONFIG.QDK and AUTOEXEC.QDK. Nothing should go wrong here.
C) In the second step:
If OPTIMIZE fails at the second step then the two likely
causes are some conflict with memory management or a conflict in
the address space. The most common cures for conflicts in memory
management are the QEMM-386 parameters "NOSH and "NT".
QEMM-386 tries to manage the unused portions of two
different varieties of Chips & Technologies shadowRAM but
sometimes incorrectly identifies a different implementation as
one that it knows how to use. "NOSH" tells QEMM-386 not to try
to use the shadowRAM, clearing this kind of error.
"NT" tells QEMM-386 not to try to manage Top Memory. This
is another kind of memory, located at the top of the 16 meg
address space, that QEMM-386 may misdetect or mismanage. If your
machine has no shadowRAM or Top Memory then these parameters will
not affect the performance of the computer.
The other likely cause of OPTIMIZE failing at the second
step is that QEMM-386 is placing High RAM in a portion of the
address space used by another device (hardware device) on the
system. If you have a network card, disk controller with ROM,
scanner with a RAM buffer, video capture card, or any of a number
of devices, you may have such a conflict. QEMM-386 does not
always recognize the address space used by these devices; an
explicit exclude parameter ("x=mmmm-nnnn") on the QEMM-386 command
line may be needed. You should consult the manuals of your hardware
to find out what pieces of the address space they use. If this is not
possible then you can follow the analysis procedure as explained in
the QEMM or Manifest manual before running OPTIMIZE or adding the RAM
parameter. If you wish to do none of these you can exclude all of the
high RAM area ("x=a000-ffff") and then cut down on this exclude
("x=c800-efff", then "x=c800-dfff", then "x=c800-d7ff", and so on; or
"x=e000-ffff", then "x=e000-efff", then "x=e000-e7ff", and so on)
until you find the smallest portion(s) of the address space that
QEMM386 must be instructed not to use to prevent the conflict.
The OPTIMIZE process can also fail at the second step if the
file "RSTRCFG.SYS" is corrupted. You can copy this file over
anew from the QEMM-386 source disk to the QEMM directory.
Finally, some programs will fail on the second step of
OPTIMIZE because they are incompatible with the LOADHI program,
even though the /GS parameter used in the second step of OPTIMIZE
prevents any actual loading into HIGH RAM. In this case you
should remark the program out (by inserting the command "rem" at
the beginning of the line on which the program is loaded) for the
duration of the OPTIMIZE process. If this program is needed in
order to load other programs, see the information on OPTIMIZE's
/L parameter in the Switches section below.
C) In the third step:
If OPTIMIZE fails at the third step then the cause is:
i) an attempt to load some driver or program high that objects;
ii) loading high into a piece of the address space that is being used
by a hardware device (conflicts are often found only when
something is loaded high into an area);
iii) the existence of a bus-mastering hard disk controller
(usually a SCSI disk controller, but others are possible
culprits).
i) If some driver or TSR misbehaves when loaded high then
the cure is to remark it out (by inserting "rem " before it on
its command line) for the duration of the OPTIMIZE process. (If
this program is needed in order to load other programs, see the
information on OPTIMIZE's /L parameter in the Switches section
below.) You may need to find out which program is causing the
problem by optimizing with the AUTOEXEC.BAT out of the way (by
renaming it to something else) to isolate the problem to the
CONFIG.SYS or AUTOEXEC.BAT and then narrowing down which
program(s) object to being loaded high by loading partial
AUTOEXEC.BATs.
ii) If an address conflict is the problem then the area in
conflict must be excluded as mentioned above in the
troubleshoooting section for step 2.
iii) If your system has a bus-mastering hard disk
controller then you must use the "db=xx" parameter on the QEMM
command line. "xx" should be a number between 2 and 10. This
parameter sets aside a buffer of "xx" kilobytes in unmapped
conventional memory for diversion of disk i/o from mapped memory.
If you do not know whether you have such a device give this a try
to see if it works. If your system has a bus-mastering disk
controller then a better solution is to use the VDS (Virtualized
DMA Services) driver that the manufacturer may have written. If
your bus-mastering device is not a hard disk controller the VDS
driver is necessary if you wish to LOADHI. See the Quarterdeck
technical note #121,"bus-mast.tec," for more information on this
subject.
DOS RESOURCES
BUFFERS: OPTIMIZE tries to load buffers high for all DOS
versions 2.x and 3.x. It does this by decreasing the buffers
loaded in the CONFIG.SYS to one and loading the rest in the
AUTOEXEC.BAT with a statement like:
"C:\QEMM\LOADHI /R:1 C:\QEMM\BUFFERS=20".
One buffer must be left loaded in the CONFIG.SYS (DOS defaults to
providing a higher number if none are specified).
1) What if I have DOS 4?
Microsoft changed the structure of buffers with version 4 of
DOS, making it possible to load buffers into expanded memory.
This is preferable to loading them high because no address space
at all is used. If you are using DOS 4 or later then you may use
the "/x" switch (e.g.: "buffers=20/x"). Note that expanded
memory can be used only in 16K increments, so that buffers loaded
into expanded memory are allocated 30 at a time; no matter how
few you specify, with the "/x" parameter you get at least 30.
Before using the "/X" parameter for DOS buffers, run Manifest and
check the "Hints" section to verify that it suggests loading
buffers high with /X. Some early DOS 4 versions have a bug which
make it unwise to use this feature. Manifest can detect this and
will not recommend loading buffers high if it detects the bug. In
addition, the /X parameter should not be used on BUFFERS until
the RAM parameter has been placed on QEMM-386.
2) What if I am using a third-party disk partitioner?
You may find that your buffers are using some huge amount of
memory. If you are creating disk partitions larger than 32 MB
with a version of DOS earlier than DOS 4, the size of each
buffer increases with the size of the sector. If you are missing
a lot of memory then you may want to check the DOS/Overview page
of Manifest to see how much space your buffers are taking. A
buffer is 528 bytes for a normal 512-byte sector. For partitions
larger than 32 MB the sector size grows by factors of two and the
buffer size follows. This has nothing to do with OPTIMIZE or
QEMM386: your buffers use this much space even if you do not run
OPTIMIZE or load QEMM-386. You can see this by comparing the
amount of memory the buffers are using in the DOS/Overview page
of Manifest with and without QEMM386.
FILES, FCBS, LASTDRIVE: OPTIMIZE does not load any of these DOS
resources high. Since they use a comparatively small amount of
memory, this does not affect most users. If you want to load them
high, you must do so by hand in imitation of the way buffers are
loaded high: decrease the number in the CONFIG.SYS to a minimum and
use LOADHI (for example: C:\QEMM\LOADHI C:\QEMM\FILES=40) in the
AUTOEXEC.BAT. Note that because the drive specifiers must be
contiguous lastdrive creates a duplicate set of drive specifiers high
for all that were loaded low. This means that the number loaded low
should be minimized in the CONFIG.SYS (for example: "lastdrive=c"
since DOS defaults to "lastdrive=e") if "LASTDRIV.COM" is used to load
drive specifiers high. Although OPTIMIZE does not load any of these
DOS resources high, once you have them loaded high OPTIMIZE will fit
them into high RAM in the location in which they will most efficiently
fit.
SHARE
If you have disk partitions larger than 32 MB with DOS 4 or greater
and are partitioning the disk with FDISK then SHARE.EXE is loaded
implicitly by DOS. Optimize will not load it high unless it is explicitly
invoked in the CONFIG.SYS, for example:
install c:\dos\share.exe
NETWORK OPTIMIZATION
If you are optimizing on a system where the COMSPEC is being
changed to a network drive then the AUTOEXEC.BAT and CONFIG.SYS
in the directory where the comspec points will be changed by
OPTIMIZE. If you want the AUTOEXEC.BAT and CONFIG.SYS on a local
drive to be OPTIMIZEd instead then OPTIMIZE can be invoked with
the "/B:a" switch (for example: OPTIMIZE /B:a) where "a" is the
drive containing the AUTOEXEC.BAT and CONFIG.SYS to be OPTIMIZEd.
SWITCHES
/B:x
This switch causes OPTIMIZE to modify the CONFIG.SYS and AUTOEXEC.BAT
files on the "x" drive.
/L
This switch causes OPTIMIZE to modify only those lines of
the CONFIG.SYS and AUTOEXEC.BAT that already have the LOADHI
instruction on them (for example: "device=c:\qemm\loadhi.sys
/r:2 driver.sys" or "c:\qemm\loadhi /r:1 c:\mouse\mouse"). This
can be used to run OPTIMIZE and leave programs that you do not
want loaded high untouched. You can do this by running OPTIMIZE,
then removing the LOADHI portion ("C:\QEMM\LOADHI /r:?") from the
line of the program that you do not want loaded high, then
running OPTIMIZE /L.
/PATH
This switch adds the OPTIMIZE path to each command line so that
"C:\QEMM\" is not added every time LOADHI is invoked. This makes these
lines shorter and may be useful for those with very long lines.
SUMMARY
OPTIMIZE is an important feature of QEMM386, QEMM 50/60, and
QRAM. It is unparalleled in loading programs into memory in the
most efficient manner. Problems running OPTIMIZE are rare and it
is worth the user's time to resolve them. Once the problem is
solved the user should be able to run OPTIMIZE in the future,
when he/she changes his/her system's configuration, without
additional difficulty.
Copyright (C) 1991 by Quarterdeck Office Systems
* * * E N D O F F I L E * * *